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Abstract 


Software Test Coverage Analyzers are very much useful in software testing pro- 
cess. It can speed-up the software testing process. But, they are language dependent 
tools; same Test Coverage Analyzers cannot be used for testing programs written in 
different languages. However, in today’s era, when people are too much concerned 
about productivity and quality, one cannot do away with Test Coverage Analyzers in 
a testing process, specially when it comes to testing big and complicated projects. 

Development of Test Coverage Analyzers is a labour intensive and time-consuming 
task. However, it has been observed that basic development process of a Test Cov- 
erage Analyzer is same, irrespective of the language for which it is developed. This 
indicates the potential for automatic development of Test Coverage Analyzers. This 
thesis proposes an approach for generating Test Coverage Analyzers. The proposed 
approach has been used to design and implement a tool, which generates Test Cov- 
erage Analyzer for a language. This tool reads two specification files, and generates 
the Test Coverage Analyzer for the language. The specification files contain 

• Probe specification, giving details of the probes and the places for them. 

• Grammar specification(YACC) for the language, for which the Test Coverage 
Analyzer is to be developed. 

The tool provides high development productivity, and also assures the quality of 
the generated Test Coverage Analyzers. Application experiences of the tool have 
shown that, a 150 lines (approximately) specification is enough for generating a Test 
Coverage Analyzer; and the productivity gain is as much as 25-35 times of the hano 
coded development. 
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Chapter 1 


Introduction 


1.1 Need of Software Testing 

The development of software systems involves a series of activities which are prone 
to human errors. Errors may occur at the requirement phase, design phase as well as 
in coding phase [Jal91]. Detection of errors in a Software requires lot of effort, as it 
is not a physical object [Bei90]. Studies have shown that, software testing consumes 
nearly half of the effort required to produce a working software system [Jal91, Bei90]. 
Due to these reasons, software development is accompanied by quality assurance 
activity, and Software Testing is a critical element of software quality assurance. 

Software Testing can be defined as a process of executing a program with the 
intent of finding errors [Mye79]. A successful test is one which uncovers an as yet 
undiscovered error. Hence, testing should be done with well-planned test cases, 
which ensures execution of all possible basic paths in the program. This is a time 
consuming task; software testing tools, that can reduce the testing time without 
reducing the thoroughness are very much valuable in this context. 

There are two basic approaches for Software testing, namely, structural testing 
or white box testing and functional testing or black box testing. Structural testing 
compares the test program behavior against the apparent intention of the source 
code, taking into account the possible pitfalls in structure and logic. Structural 
testing is also known as path testing. On the other hand, functional testing examines 



what the program accomplishes, without any regard to how it works internally. That 
is, functional testing is concerned with examining the behavior of the program wuth 
respect to the requirement specification. 

1.2 Test Coverage Analyzers 

In a software testing process, an important decision to be taken is when to stop 
testing. The testing process can be said to be over if the test cases meet the de- 
sired level of coverage of the different constructs. That is exactly what a Software 
Test Coverage Analyzer does. A Test Coverage Analyzer automates the process 
of [Cor96]; 

• finding the areas of a program, that are not covered by test cases 

• determining quantitative measure of test coverage, and 

• creating additional test cases to increase coverage. 

Another aspect of Test Coverage Analyzer is to eliminate redundant test cases. 
Test Coverage Analyzers are used for assuring the quality of the test cases, which' 
assists in assuring the quality of the actual product. 

The testing technique automated by a Test Coverage Analyzer is known as Test 
Coverage Analysis. Some of the fundamental assumptions behind this technique are 

• faults relate to control flow and can be exposed by varying the control flow [Bei9C 

• A successful test run implies program correctness [Mor90]. But it does not 
mean that program is free of bugs; the quality of the test case should also be 

measured. 

• The test program should not have any unreachable codes. 

Test Coverage Analysis is a structural testing technique. Basically, a Test Cov- 
erage Analyzer takes a source program as input, and inserts software probes into the 
source code. Using these software probes, it monitors the test run of the program and 
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determines the coverage measures. The ideal places in a program, where the probes 
to be pzz are the places, where transfer of control takes place (e.g branch statement, 
procedure call, relational expression, task entry point etc. ), so that traversal of any 
basic path can captured. However, optimal probe insertion techniques are available 
in the uterature [RKC75, Pro82, Aga94]. 

1.3 Some Of The Basic Coverage Measures 

There are a large variety of Coverage measures used by different Test Coverage 
Anah’zers. Detailed discussion of all these measures is out of the scope of this 
report. Brief ideas about some of the basic coverage measures are given below. 

Statement Coverage : This measure - also known as line coverage, basic block 
coverage, or segment coverage - reports whether each executable statement is 
executed or not, for a given test case. The main advantage of this method 
is that it can be directly applied to the object code and does not require the 
processing of the source code. Performance profilers commonly implement this 
measure. This coverage measure is insensitive to the some control statements 
conditions; it cannot check whether all the branch options has been covered 
or not [Cor 96]. 

Branch Coverage : This measure reports whether all the branch possibilities are 
explored by the test case or not. The entire boolean condition in a branch 
statement is treated as a single true-and-false predicate and coverage reporting 
is done on the basis of that. This category also includes coverage measures 
for switch statement’s cases and exception handlers. Branch Coverage is also 
known as decision coverage, basic path coverage or all-edge coverage. This 
type of coverage does not consider the branches within the boolean expression, 
that may occur due to the logical operators [Cor96]. For example consider the 
following code segment 
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if ( conditionl kk (conditionB 1| functionlQ)) 
statementl; 
else 

statement2; 

In this example, the test condition is true when conditionl and condition2 are 
true, and false when conditionl is false. So, in such situations, there is no need 
to make a call to functionl(). The branch coverage measure may consider the 
control structure completely exercised, without a call to functionl(). 

condition coverage : This measure reports the true or false outcome of every 
boolean subexpression separated by logical operators. It reports each sub- 
expressions separately. The advantage of this measure is the thoroughness in 
testing [Cor96]. 

Path Coverage ; This measure reports whether all the possible paths in each func- 
tion or procedure has been executed or not. A path is a unique sequence of 
branches from the entry point to the exit point of a module(i.e. function or 
procedure). This measure achieves the maximum thoroughness in testing; but 
the number of paths in a program is exponentially related to the number of 
branches and hence requires a large number of software probes to monitor all 
the paths. For example, a function, containing just 10 if statements, has 1024 
paths to test. Adding just one more is statement, it goes up to 2048. Another 
disadvantage is that many paths arc impossible to exercise due to relationship 
of data. For example, consider the following code segment. 

if ( success ) 

statementl; 
statements; 
if (success) 

statements; 

Path coverage measure will show that there are four possible paths. But, ir 
reality, there are only two paths( 5 uccess == true and success == false). 
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Function Coverage : This measure reports whether each procedure and function 
defined in the program has been invoked or not. 

Call coverage : This measure reports whether each procedure/function call in the 
program has been executed or not. The assumption behind this measure 
is that, faults may occur in interfaces between modules. This measure is 
different from the previous one in the sense that function coverage deals with 
measuring the coverage of the functions/proccdures defined in the program, 
not the procedure/function calls. 

Loop Coverage ; This measure reports about how many times the body of a loop 
has been executed for a a test case. 

Data flow coverage : This is a variation of path coverage. This measure deals 
with coverage of sub-paths from a variable assignments to its subsequent ref- 
erences. This measure has direct relevance to the way a program handles the 
data; but it does not consider the branch coverage. Further, this measure is 
very complex to implement. 

Race Coverage : This measure reports whether multiple threads/task is executing 
the same code simultaneously. This measure helps in detecting the faults in 
multi-thrcaded programs. 

Relational Operator Coverage : This measure reports whether boundary sit- 
uations occur with the relational operators. That is, it reports the exact con- 
dition which causes a particular branch evaluation. The assumption behind 
this measure is that boundary test cases find off-by-one errors and incorrect 
uses of relational operators such as < instead of <=. For example consider 
the following C-i-f code segment. 

if (a < h) 

statement; 

Relational operator coverage reports whether the boundary condition a==b 
occurs or not. 
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Weak mutation Coverage : This measure is a generalized form of Relational Op- 
erator Coverage. It tries to expose the use of wrong operators and operands. 
It works by substituting ( mutating ) the expressions in the program with the 
alternative operators(e.g. substituting and also with alternative vari- 
ables for reporting the coverage of the conditions [How82]. 

Table Coverage : This measure reports whether each entry in a particular array 
has been referenced or not. This is useful for testing programs which are 
controlled by finite state machines, such as parser. 


1.4 Setting Up Coverage Goals 



Figure 1.1: Coverage rate( Courtesy[Cor96] ) 

It is important to set up the coverage goal for each product, in order to assure the 
quality of the product. Each project must meet some minimum percentage coverage 
criteria for release, so as to prevent post-release failures [Cor96]. Of course, this 
percentage is dictated by the testing resources and the nature of the product. For 
example, a safety-critical software must have higher coverage goal. 
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Apart from the final coverage goal, it is also necessary to set up intermediate 
coverage goals as it helps in increasing the testing productivity. Testing productivity 
increases, if and only if most of the failures can be found with the least effort ( 
includes, time required to create test cases, add in the test suit, and run them 
). Test coverage analyzers do help in achieving this. They provide the highest 
probability of finding bugs in least time. Figures 1.1 and 1.2 shows the Coverage 
rate and failure discovery rates for low and high productivity testing respectively. 


Failures 



Figure 1.2: Failure Discovery rate( Courtesy [Cor9 6] ) 

One way to achieve high testing productivity is to first attain some coverage 
throughout the entire source program before going for high coverage for any partic- 
ular area in the program. The hypothesis is to look for failures which can be easily 
found by minimal testing. Coverage goals for these intermediate testing session 
should be set up to achieve effective and high-productivity testing. 
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1.5 Coverage Measures Incorporated In This Work 

In this thesis work, we have designed a Test Coverage Analyzer for Ada’95, and a 
tool for automatic generation of Test Coverage Analyzers. Present implementation 
incorporates the following coverage measures. 

• Function Coverage 

• branch coverage 

• loop coverage 

• Call Coverage 

• block-wise coverage 

The detailed discussion of this work is carried out in the following chapters. 

1.6 Organization Of The Thesis 

This thesis has been organized as follows. The next chapter gives a brief- idea about 
the ongoing works in the development of Test Coverage Analyzers. In this chapter, 
a brief overview about the features of some of the the well-known Test Coverage 
Analyzers are given. We have also looked into the works that have been already 
done in IIT Kanpur. Finally, a few words about our thesis work, its philosophy, and 
the motivation behind this work, are outlined in this chapter. 

Chapter 3, describes a design approach for Test Coverage Analyzers. The step- 
by-step approach for the design, with an intention to find out the potential for 
automating these step, is outlined in this chapter. The design discussed in this 
chapter has been used to design and implement a Test Coverage Analyzer for Ada’95. 
A brief discussion about the implementation issues is also carried out in this chapter. 
Finally, the scope for the automatic generation has been pointed out here. 

The fourth chapter enumerates the issues in design and the implementation of a 
tool for Automatic generation of Test Coverage Analyzers. A comprehensive design 
for achieving this is also discussed here. 
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Chapter 5, speaks about the application experiences of both the tools imple- 
mented under this thesis work. The results of the performance evaluation of the 
generated Test Coverage Analyzers for the languages C, and Ada’95, in comparison 
to hand-coded Test Coverage Analyzers, are also outlined in this chapter. 

The complete user’s manual for GCTA( Generic Test Coverage Analyzer, the tool 
used for generating Test Coverage Analyzer ), is given in Appendix A. Appendix B 
gives the User’s manual for ADACOV(Test coverage analyzer for ADA’95), and also 
speaks about how to interpret output of the coverage tool. 
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Chapter 2 
Background 


This chapter gives a brief overview of some of the existing commercial and non- 
commercial testing tools, that support Test Coverage Analysis. A brief introduction 
to our work, and the philosophy behind it, are also outlined in this chapter. 


2.1 A Survey Of Some Well-known Test Coverage 
Analyzers 

There are a number of Test Coverage Analyzers in the commercial/non-commercial 
software product domain; and it is not possible to describe all of them. Some of the 
well-known Test Coverage Analyzers, and their features are enumerated below: 

AdaTEST ; This is a widely used Testing tool, from Information Processing Limited^ (IP 
for Ada programs. This is a complete software testing environment with the 
capabilities of dynamic testing, coverage analysis, and static analysis. As dy- 
namic Testing, AdaTEST supports functional testing, structural testing and 
the timing analyses. AdaTEST provides the facilities for coverage analysis of 
single units, package, tasks, and the entire Ada System. It incorporates state- 
ment, branch and condition coverage. It also provides code audit facilities for 
assessing compliance with coding standard and measuring code complexity, as 
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well as calculating many of the published matrices(e.g. McCabe, Halstead); 
it can also be configured to use non-standard(i.e. user-defined) matrices in its 
analysis. The testing results are reported in an easy to read form. Currently, 
work is going on to incorporate testing capabilities of Ada’95 programs, and 
the name of the tool has been provisionally kept as AdaTEST’95. 

Cantata : This is a Software Testing tool Developed and marketed by IPL, and 
provides a complete Software Testing environment for C and C-t— I- programs. 
The capabilities are exactly same as AdaTest, and supports dynamic testing, 
coverage analysis, and static analysis for C and C-h-b programs. 

C-Cover : This is a Software Test Coverage Analyzer, developed and marketed 
by Bullseye Testing Technology^, for C and C-H— f- Programs. The tool incor- 
porates the capabilities for branch, function and condition coverage. Unlike 
Cantata, It does not support static analysis and complexity measures. 

GCT : GCT(stands for Generic Coverage Tool) is a free-ware coverage tool that 
measures how thoroughly tests exercise C programs. It supports the following 
coverage measures 

• branch coverage 

• multiple-condition coverage. 

• loop coverage 

• relational operator coverage 

• function coverage 

• call coverage 

• race coverage 

• weak mutation coverage 

GCT has been widely used in production environments, including testing the 
UNIX kernel. The tool takes C source code, adds instrumentation, then uses 
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the system C compiler(or a compiler of user’s choice) to produce an object file. 
Alternately, the instrumented source can be captured and moved to another 
machine for compilation. GCT is designed to work with existing makefiles (or 
other system build mechanisms). Most makefiles will require no changes. For 
the sake of efiiciency, coverage information is stored in an internal log. The 
log is written on exit (or, in the case of an unending program like the UNIX 
kernel, extracted from the running program). 

GCT is one of the most versatile Test Coverage Analyzers and is a public 
domain software developed under GNU general public license agreement. The 
details of GCT can be obtained from GCT documentation [Mar96]. 


2.2 Work Done At IIT Kanpur 

In the Department of Computer Science and Engineering, at IIT Kanpur, some work 
has been done in the area of Software Test Coverage Analysis. A Test Coverage 
Analyzer for C, named CCOV [Sha91, Pal93], and test data generator [Pal93] have 
been designed and subsequently implemented. Works on several static analysis tools 
for complexity measurement, style tool etc. have also been carried out here. 

2.3 About This Thesis Work 

After reviewing the current works in the domain of Test Coverage Analyzers, it has 
been found that all these works are more or less similar, with some variation regard- 
ing the coverage measures. At the same time, we noticed that the development of 
Test Coverage Analyzers is a labour-intensive and time-consuming task. For exam- 
ple, the total size of the source code for GCT, is about 6MB. As the development 
approach for all these tools, are more or less similar, there is a possibility of a gener- 
ative approach for developing Test Coverage Analyzers. Keeping this idea in mind, 
we looked through several journals and Internet to find whether any work of this 
kind has been going on or not. And we found that, no work is going on regarding 
automatic generation of Test Coverage Analyzers. This is the basic motivating force 



for taking up this challenging topic under this work. 

Significant work has been going on in the compiler domain, regarding its au- 
tomatic generation. Compiler generators like GAG [KHZ82], COCO [Mos90] etc. 
are a few of the examples. These tools read some sort of specification file, and 
generate compilers, or one or more components of a compiler. Our objective is to 
develop similar kind of tool for Test Coverage Analyzers, which will generate Test 
Coverage Analyzer for a language after reading some sort of specification. The phi- 
losophy behind our thesis work is to case the work of developer for developing a 
Test Coverage Analyzer. Further, programming is not reliable, and the reliability 
of any software decreases with the increase in code size; and Software Test Cover- 
age Analyzers involve lot of programming. One of the objectives of this work is to 
minimize programming from the development process. Instead of that, if we can 
provide some well-tested software, which can generate test coverage analyzer with 
minimal information from user side, it would provide an efficient and easy way for 
developing Test Coverage Analyzers. 

A generative approach has the highest potential for productivity [PD93], and at 
the same time, it reduces the cost of the software(usually, the commercial testing 
tools are very costly). Apart from productivity gain, the generated software also 
assures quality. 

T his thesis work is centered around the automatic generation of Test Coverage 
Analyzer. We designed and subsequently implemented a generator for accomplishing 
this task. The generator takes a specification and the grammar rules as input, and 
generates the Test Coverage Analyzer for the language specified by the grammar. 

The detail discussion' about our work has been given in the following chapters. 



Chapter 3 

A Design Approach For Test 
Coverage Analyzers 

Methodologies adopted for designing Test Coverage Analyzers are more or less sim- 
ilar irrespective of the language for which it is designed. Our intention is to find out 
the steps that are carried out manually and issues regarding coverage monitoring, 
maintenance and reporting. With this motivation in mind, we describe an approach 
for designing a Test Coverage Analyzer in this chapter. The proposed approach has 
been used to design and subsequent implementation of a Test Coverage Analyzer 
for Ada95 [Whe96]. 

3.1 A Design Scheme 

3.1.1 Various Phases in The Design Process 

The basic task of a Test Coverage Analyzer(TCA) is to find the places, where the 
probes are to be put, and instrument the source program, with an intention of in- 
corporating certain coverage measures. To accomplish this task, it needs to parse 
the source program. A comprehensive description of different parsing techniques 
are given in the “Dragon Book” [ASU86]. After identifying the place, TCA instru- 
ments the source program, by inserting some software monitors. A block diagram 
showing various phases for development of Test Coverage Analyzer, and the overall 
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architecture is shown in Figure 3.1. 



Figure 3.1: Functional diagram of Test Coverage Analyzer 


The grammar specification file contains yacc specification for the grammar of the 
source language - in this case Ada95. 

The process “Instrument Grammar file” is the most important and crucial one 
in the whole development cycle. Basically it involves three main activities, and arc 
normally carried out manually. They are : 

• Identifying places for probe actions, in the grammar(YACC/BISON specifica- 
tion) file. 

• Inserting probe actions, and 

• Writing supporting modules and data structures 
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I Identifying Places for Probe Actions 

This activity is dictated by the coverage measures to be incorporated by the Test 
Coverage Analyzers. Our design of TCA for Ada95, takes into account of Branch 
coverage, Call coverage, Function Coverage and Loop coverage. Thus, the places for 
the probes are at the points where transfer of control takes place (for branch coverage 
and loop coverage), at the entry point of a procedure and function definition(for 
function coverage) and just after procedure and function call statement(for Call 
coverage). The YACC production rules for these places has to be identified, in order 
to put probe actions. 


Type of the 

Begin linenumber 

End linenumber 

tabs 

depth 

block 







1 


1 

1 

1 


/ 

Figure 3.2: Structure of Block Table 


I Inserting Probe Actions 

This activity is concerned with inserting probe actions in the selected production 
rules. The nature of this action may vary depending upon the design criteria. Our 
design adopts a two-pass strategy for inserting probes into the source program. In 
the first pass, a table is constructed to contain the information about the various 
blocks and statements at which the software monitors are to be put. This table is 
named as “block table”, whose structure is shown in figure 3.2. This table stores 
the information about the statement type( e.g. ifjstatement while-statement etc.), 
whether begining or ending of a block, line number, tab setting( for beautifying 
the instrumented source program ), and the depth of the block (nesting level). The 
depth information is used latter for showing the skeleton block structure of the test 
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program, which can be used for verifying the coverage results. The probe actions 
to be inserted in the selected production rules are concerned with constructing this 
table, and storing the locations of the probes to be inserted in the source program. 

The software probes are inserted in the instrumented source file during the second 
scanning(i.e. pass 2) of the source file. How this task is accomplished, is discussed 
in the next section. 

I Writing Supporting Modules 

This activity involves, writing supporting routines for generating instrumented pro- 
gram. These routines read source program and block table, and inserts probes in 
the test program. Writing modules for generating the supporting routines for the 
probes in the test program are also included in this activity. These routines should 
be in the language used by the test program. 

At the end of the phase “Instrument Grammar file” , we have the instrumented 
grammar file, and supporting modules, which, if compiled, gives a module called 
“Program Instrumenter” . “Program instrumenter” generates the instrumented source 
program. In this thesis, this module is synonymously used with Test Coverage An- 
alyzer. 

3.1.2 Instrumenting Source Program 

Software monitors are inserted into the source program by the software module 
called “Program Instrumenter” . Figure 3.3 shows the functional architecture of this 
module. Basically, this modulo consists of three components. They arc, 

• Source Program Reader 

• Probe locator, and 

• Instrumenter 
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Instrumented 

Source 

Program 


Figure 3.3; Functional Architecture of Program Instrumenter 


Source Program reader , reads the source program and provides information 
regarding the begining and ending of the blocks, and the location of the 
probes to be inserted, to the Probe Locator. It consists of two components, viz. 
“scanner” and the “parser”. If, the input source program is not syntactically 
correct, it reports syntax error, and does not allow instrumenter, to instrument 
the source program. 

Probe locator constructs block table, and also stores the position of the probes in 
some table, depending upon the information provided by the Source program 
reader. This component operates in the first scanning of the input source 
program. Structure of the block table is shown in figure 3.2. 

Instrumenter inserts software probes in the source program, with the help of the 
block table and the table, storing the probe locations. It operates in the second 
scanning of the source program. The algorithm used by the instrumenter, to 
instrument a program is given in the figure 3.4. 
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Algorithm InstrumentProgram( progfile ) 
while (not ( end- 0 f -file ( progfile ))) 
ch = next-char( progfile) 
putcharacter(ch, instrumented-file) ; 
iff ch == newline ) 

iffcurrent-lineno == block-tablefcurrblockJ.beginJineno) 

/* For constructs like return statement, goto 

* statement, procedure call etc., which are not 

* blocks, begin-lineno and endJineno 

* will have the same value 

V 

cons-type= block-tablefcurrblock] . type; 
bline — block-tablefcurrblock]. beginJineno; 
eline = block-tablefcurrblock]. end-lineno; 
insert-probe( cons-type, bline, eline); 
endif; 

current-lineno = currentJineno + 1; 
iff nextblock == nil and current-lineno == 
block-tablefblok-Of. end-lineno ) 

/* in the main block, put coverage-reporting 
probes */ 

insert-coverage.report-probe(block-tablefblock-0].type); 
insert-COverageJiistory-probefblock-tablefblock-Of.type); 
elseiff current-lineno >= block-tablefnextblockf.beginJineno) 
currblock = nextblock; 
nextblock = getnextfnextblock); 
endif; 
endif; 
endwhile; 

end InstrumentPrograrn; 


Figure 3.4: Algorithm for instrumenting source program 


3.1.3 Coverage Reporting 

The instrumented source program contains probes for 

• monitoring the coverage of different constructs, 

• maintaining the coverage information across several test sessions, and 
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• generating the coverage reports. 

The instrumented source program gives the coverage statistics for a given set of test 
cases, with the help of these probes. 

Test Coverage Analyzer, generates the supporting routines for the software probes 
inserted in the source program. These routines includes probes for coverage mon- 
itoring, coverage history maintenance, and coverage reporting. Coverage statistics 
are generated by these routines, which is used to determine the stopping point for 
software testing operation. 

3.1.4 Multi-Session Testing 

Software testing operation usually spans for mqre than one testing session. Each 
session has different set of test cases, and coverage outcome for each of them may 
be different. The cumulative coverage outcome of the different test session is an 
important factor to decide the stopping point. Thus, the Test Coverage Analyzer 
should maintain the Coverage History of these test sessions and report about the 
cumulative coverage. One simple way to incorporate this feature is to maintain a 
coverage history file, which stores the cumulative coverage information of all the 
test sessions. Whenever a new test session is started, the cumulative coverage infor- 
mation from the history file will be loaded and the new values are evaluated using 
the current coverage. After reporting the coverage statistics, these values will be be 
written back to the history file. 

3.2 Implementation Issues And Decisions 

• To make a quality Test Coverage Analyzer for a language, the first requirement 
is the correct and well-tested grammar for the language. We have used stan- 
dard and well-tested grammar for Ada’95 available in the public domain. It 
was a YACC specification file associated with the Lexical analyzer for Ada’95 (a 
Lexfile). 
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• Another implementation issue was the .type of coverage measures to be incor- 
porated in the tool. Although there are several coverage measures (refer to 
chapter 1), ADACOV implements the following coverage measures. 

— Branch coverage Information (Includes If statement, case statement, while 
loop, simple loop, for loop, case when components of case statement 
and exceptions, Ada task, Select Statement, accept statement, goto and 
return statements) 

— Function coverage, 

- loop coverage for all the loops and tasks, 

— Call coverage, 

— Block-wise coverage statistics, 

- cumulative coverage for the afore-said coverage measures. 

• ADACOV supports multi-session testing. Our implementation maintains a 
History file across various testing session, and at every testing session, the 
cumulative coverage for all the aforesaid measures are reported in a compre- 
hensive manner(see Appendix B, for sample output); this file is updated at the 
end of every test session. The history file contains the following information. 

- Type of the statement( e.g. if.£tatement, whilejstatement etc.) 

- Line number at which the construct begins. 

- Line number at which the construct ends, and 

- Number of times, it was covered. 


3.3 Scope for automatic generation 

The objective of this work was to explore the possibilities of automatic develop- 
ment of TCA. Our design shows that the proposed approach can lead to automatic 
generation of TCA. 



In this approach, the only manual phase, is “Instrument Grammar File” shown 
in the figure 3.1. This is the most crucial phase, and is dictated by the grammar 
of the language, and the coverage measures to be incorporated. Other phases are 
same for all languages and can be easily carried out automatically. If we automate 
this phase, then the whole development process will be an automated one. In other 
words, automatic generation of TCA, primarily means automating this phase. 
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Chapter 4 


Automatic Generation Of Test 
Coverage Analyzers 


In chapter 3, we have shown that Automatic Generation of TCAs can be achieved 
by automating the phase “Instrument Grammar” of the design approach. This 
chapter describes our approach for automating the phase. We also describe various 
design and implementation issues to accomplish this. The tool, which generates Test 
Coverage Analyzers, has been named as Generic Test Coverage Analyzer ( GCTA ). 
for our discussion in this report. 

4.1 A Design Scheme 

4.1.1 Design Considerations 

• The primary task of the GCTA is to instrument the grammar specification 
of the source language with probe actions. The nature of these actions are 
dictated by the design criteria. In our case, these actions store the probe 
locations in block table. In order to instrument the grammar specification file, 
GCTA should be informed about the productions on which the actions are to 
be added, and what would be the action. One solution for this, is to use a 
specification file [GE90]. GCTA uses a specification file, which contains the 
specifications for the places in which probe actions to be put and what probes 
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are to be put. The syntax and semantics of the specification language is an 
implementation issue, and is discussed latter in this chapter. 


• Our experience with design of Test Coverage analyzer for C and Ada’95 is 
that, the action part of all the grammar rules is more or less similar with 
little differences. These differences are dictated by the coverage measures to 
be incorporated, and semantics of the construct. For example, consider the 
following production for WHILE statement in C, and the action associated 
with it. 

iteration^statement ; WHILE ’(* expression *)* 

■C 

curr _blo ck_depth++ ; 
block.marker ♦bmark; 

bmark=new block.inarker(‘*{" , TCA.LineNum, 1, curr_tab„set ,curr_block_depth, WHILE.STMT, 3); 

marker.list . insert (bmark) ; 

curr_tab_set++; 

} 

statement 


The action part of the productions for other statements like for statement, if 
statement etc. will be similar to this, except the name of the construct (e.g 
WHILE-STMT) will be different. Further, these actions involve complex ta- 
ble handling operations, as shown in the example. Our approach hides the 
complexity of these actions, by providing some specific directives. The probe 
actions are generated automatically, depending upon the values assigned to 
these variables/directives. Appendix A describes the detailed usage of these 
variables and directives. User can directly specify the probes also. 

• The current design supports automatic action generation for branch coverage, 
loop coverage, function coverage, and the Call coverage. If a user wants to in- 
corporate other coverage measures, (s)he has to write actions for it. Our design 
can be extended to incorporate automatic action generation for new coverage 
measures. It can be done by adding supporting modules and directives. 



4.1.2 Design 

I Functional architecture 



Figure 4.1: Functional diagram of Generic Test Coverage Analyzer 

Figure 4.1 shows, the functional diagram of GCTA; it is similar to that of TCA, 
shown in Figure 3.1, except the new module “Grammar Instrurrienter” . This module, 
consists of two components, namely 

• spec-parser, and 


• driver 

Spec-parser reads the probe specification file, checks its syntactic correctness and 
generates various tables to be used for instrumentation. The probe specifica- 
tion file(refer to Appendix A) contains the production rules of the constructs 
for which coverage statistics are to be generated, and the specification of the 
probes. Apart from the symbols in the grammar specification file, a produc- 
tion in the probe specification may contain some extra symbols for specifying 
the places for probes in a production. Spec-parser identifies these symbols, 




and other GCTA directives, as discussed in the next section. The probe spec- 
ification file is read prior to reading the grammar specification, which is to be 
instrumented with appropriate actions. 

Driver instruments the grammar specification, depending upon the values in the 
tables constructed by Spec-parser. While instrumenting, it also generates the 
supporting modules for those actions. 

I Architecture of spec-parser 


probe Spec Reader 


Probe Specification i 
File 


Sciinncr 


Parser 


Spec 

Driver 


Spec Parser 


Temporary 
Probe Database^ 


Production Table 


Values 
of 
the 
Directives! 


Figure 4.2: Functional architecture of Spec-parser 

The functional architecture of “Spec Parser” is shown in Figure 4.2. It consists 
of two modules. They are 

• Probe Specification Reader, and 

• Spec driver 

Probe specification reader , reads the probe specification file, and extracts the 
values of the different directives and production symbols. If the specification is 
syntactically correct, it provides these information to spec driver. Otherwise, 
it reports error. The syntax checking is done by the parser component. 





Spec Driver , constructs the various tables(refer to section 4.1.3) and temporary 
databases, depending upon the information provided by the reader. One of 
the tables is the “production table”, which stores the productions to be in- 
strumented. This table stores the rule number, left hand side, and right hand 
side symbols of each of the production rule. Details of the table management 
is discussed in section 4.1.3. 

The probe specification may contain three types of probes, namely, 

• probes to be put into the instrumented grammar specification, 

• probes to be put in the instrumented source program, and 

• some directives to the driver, to generate some special probes 

Spec driver differentiates these probes through some specific GCTA direc- 
tives(see Appendix A), and stores them in separate temporary files. These 
temporary files are latter used by the driver module of the “Grammar In- 
strumenter” to instrument the grammar specification, and for generating the 
supporting modules. 

I Architecture of driver 

The driver module of the “grammar Instrumenter” consists of four components, as 
shown in Fig. 4.3. They are, 

• Grammar specification reader 

• Rule Comparator 

• Probe Generator, and 

• Instrumenter. 

Grammar specification reader reads the grammar specification file, and pro- 
vides each production rules to the rule comparator. The grammar specifica- 
tion file also contains some other informations, like token declaration, variable 




Figure 4.3: Functional architecture of Driver 

declarations etc., apart from the productions. This information is directly pro- 
vided to the instrumenter, in order to dump them as-it-is(or, with a little bit of 
customization, as discussed latter) in the instrumented grammar specification 
file. 

The production rules are supplied in the form of two components, viz., lhs( left 
hand side), and rhs(right hand side) of -the rule, to the rule comparator. The 
left hand side is just a character string( because, in Context Free Grammar, 
Ihs of a production cannot contain more than one symbol), and rhs is a linked 
list of symbols. If the rule comparator cannot find any match, the production 
rule must be dumped as-it-is in the instrumented grammar file. This is done 
by the instrumenter. So, the grammar specification reader, provides the rule 
to the instrumenter as well. 

Rule comparator compares each production rule in the grammar specification, 
with the rules in the probe specification files. The productions in the probe 
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specification file has already been stored in the production table{reiev to fig- 
ure 4.6), and the rules in the grammar specification are provided one rule at 
a time, in the form described above. If a match is found, rule comparator 
provides the rule number of the production to the probe generator, otherwise, 
it returns -1. While comparing the rules, it discards the additional symbols, 
used in the probe specification for indicating the places of the probes in a 
production rule. 

probe generator generates the action part of the productions, for which match 
has been found in the probe specification file. It uses the values of the direc- 
tives, assigned by the user, for generating the action. If no GCTA directive is 
used to specify the probes in the probe specification, they are treated as the 
probes to be inserted into the instrumented source program. If the produc- 
tion in the grammar sj^ccification file already contains some actions, that is 
merged with the generated actions. After generating the action, it writes the 
action into a temporary file. The successive records in the temporary file are 
separated by some special symbol. 

Instrumenter inserts the actions for the productions in the grammar file, for 
which a match is found in the probe specification file, and generates the in- 
strumented grammar specification file. For accomplishing this task, it reads 
probe database, and uses the information provided by specification reader, rule 
comparator, and the probe generator. It also generates, the supporting rou- 
tines, including the makefile and complete source distribution for the generated 
Test Coverage Analyzer barring the lexical analyzer. 

I Algorithms 

The algorithms used by the spec-parser and the driver modules of program instru- 
menter are given in figures 4.4, and 4.5 respectively. 
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Algorithm spec-parser(probe-spec-file) 
error.count = 0; 

Read the probespec-file, and while reading, 

Construct production table 
Extract the values of the directives 
differentiate the probes to be written into the 

instrumented grammar and program files, and store 
them in temporary files. 

Generate the language dependent probe codes. 

Find useless nonterminals and productions in probespec-file. 
If found, report them and increment error.count. 

cud spcx.-parscr 


Figure 4.4: Algorithm for spec-parser 


4.1.3 Table Management 

GCTA internally manages few tables, in order to instrument the grammar file, and 
for generating the supporting modules. One of these tables is the production table. 
Each entry in this table contains three fields, namely, the production rule number, 
pointer to the lhs(left hand side) symbol in the symbol table, and a pointer to a 
list storing the right hand side(rhs) of the production. This list stores the pointers 
to the symbols in the rhs of the rule. Figure 4.6 shows the structure of this table. 
Symbol table stores the inforuiatiou about all the symbols in the probe specification 
file. GCTA needs the name of the symbol only. The implementation detail of the 
production table is given Appendix B. 


Other tables include 

• a table for storing the probe nonterminals(these are the extra symbols inserted 
in a production in the probe specification file, to indicate the places for the 

probes), 

• a table for storing the construct names to be used for coverage reporting, 

. a table for storing the index of the probes stored in the temporary databases, 
for each production rule to be instrumented. 


30 




Algorithm driver (gramspecjile) 
if (error^count > 0) 

/* If there is any error in the probe specification, 

* do not instrument 

V 

return 

endif; 

puLinslrumc.ntJi('.adc.r(ins.gramfile); 

/* Declare the global variables, data types etc. in the instru- 

* mented grammar file, that will be required by the actions 

V 

while (not (end-of. file ( gramspec-file ))) 

current-section = check-section(gram-spec-file); 
if (current-section <> grammar. rule-section) 
copy.section( current-section, ins-gramfile); 
else /* read and instrument productions */ 
while (not( end-of( grammar-rulesection))) 
curr.prod = get-production(gram-spec-file); 
ruleno = compare-rule(currjprod, prod-table); 
if(ruleno < 0) 

/* If no match is found */ 
copy.production( curr-prod, ins-gramfile); 
else 

generate-action( ); 

instrument-production (ruleno, ins-gramfile); 
endif; 

merge-action.part(gram.spec-file, ins-gramfile); 
f* If the grammar specification, contains some action 

* associated with the current production, merge(copy, in 

* case, no matching is found)it 

V 

endwhile; 

endif; 

endwhile; _ , 

/* generate supporting source distribution y 
generatesupporting.routinesO; 
generate.makefile() ; 

End driver; 


Figure 4.5: Algorithm used by the driver 
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Symbol Table 

Figure 4.6: Structure of the production table 


• a table for storing the probes to be inserted into the final instrumented pro- 
gram, when a particular construct is scanned by the TCA. This table is re- 
quired, because the source program is instrumented by the generated Test 
Coverage Analyzer, not by GCTA. This table is dumped (in the form of a 
table of structure) in a file of the output source distribution, along with a 
supporting module. This module reads this table and inserts the probes into 
the instrumented source program. 

All these tables are basically linked lists with one or two fields. 
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4.1.4 Output Of GCTA 


The output of GCTA comprises of the instrumented grammar file, and the complete 
source distribution barring the lexical analyzer for the language for which the Test 
Coverage Analyzer is generated. The generated source distribution follows the design 
described in chapter 3. GCTA also generates the makefile for this distribution, 
leaving the entry for Lex-file blank. User has to make a little modification in the 
makefile and in the lex-file. The details can be obtained from Appendix A. 

4.2 Implementation Issues And Decisions 

• The first implementation issue was about the syntax and ^semantics of probe 
specification language. If the specification could be written in some standard 
specification language, user will require minimum effort to learn it. After re- 
viewing several specification language used by standard tools like LEX [LesTS], 
YACC [Joh75], etc. we decided to accept the language used by YACC as the 
specification language for the GCTA. The primary reason for this selection 
is that, the probe specification contains some production rules, actions, and 
some language specific codes. A YACC specification file may contain all these, 
and it is a popular specification language for specifying grammar rules. 

• The next implementation issue was about the parser(i.e Spec-parser) for the 
specification language. We have used BISON (GNU YACC)^ to parse the 
probe specification file, because it is a public domain software and the source 
codes are easily available. We used BISON as a module, which checks the spec- 
ification file for correctness and provides the necessary tables to the driver. The 
production table, discussed in the section 4.1.3, is constructed by BISON. The 
driver uses this table while instrumenting the grammar specification (which is 
a BISON specification file). 

• Our design approach makes an attempt to minimize the user efforts in specify- 
ing the actions for the productions in the probe specification. The mechanism 

’■Source distribution can be obtained from http://sunsite.unc.edu/pub/gnu/bison-l.25.tar.gz 
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is to introduce some GCTA variables and directives, as discussed in the sec- 
tion 4.1. The syntax for si)ccifying these directives /variables should not violate 
the syntax of the specification language. We decided to use these directives 
in some specific section of the probe specification. The details about these 
directives/variables are listed in Appendix A. 

• An action in the probe specification file may contain three types of probes 
discussed earlier. How to distinguish them, is a major implementation issue. 
Our implementation uses the convention that any action statement without 
some special directive means that, it is to be inserted in the final instrumented 
program. 

• Another question that came to our mind was about the additional nonterminals 
used for specifying location of probes in production rules. Here also, we decided 
to use a GCTA directive for differentiating these nonterminals, with those in 
the grammar specification. 

• Once a program is instrumented with user defined probes, user would like 
to provide codes for them. For example, suppose a user specifies a func- 
tion/procedure call in a probe; then user should be able to define that func- 
tion/proccdure in the source language of the program. Wo decided to allow 
users to write such codes after the probe specification in the spec-file (i.e af- 
ter the 2nd “%%”)• Some specific GCTA directives (see Appendix A) are also 
provided to customize these codes. 

• Another implementation issue was about the target language in which the 
grammar actions, and stipporting functions arc to be generated. Our prior 
implementation of Test Coverage Analyzer for Ada95 was done in C++ Pro- 
gramming Language [Str94], and we found it convenient to handle complex 
data structures. Thus we decided to use C-1-+ as the target language for 

GCTA. 
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Chapter 5 
Results 


5.1 Development Environment 

Both the tools(i.e. ADACOV and GCTA) have been developed and implemented 
under the following environment. 


Machine 

Operating System 

Language 

Utilities 


: DEC Alpha, 2000 4/233 server 
: DECOSF/3.0 
; Ch — t and C 
: BISON, FLEX, Make 


ADACOV has been developed in C++ language, and GCTA in C. The total 
source distribution contains around C500 Lines of Code for ADACOV, and around 
12000 Lines of Code for GCTA. 


5.2 ADACOV 

5.2.1 Salient Features 

• ADACOV can be used as Test Coverage Analyzer, with the coverage measures 
stated in chapter 3. 

• ADACOV can be used as a beautifier for Ada’95 program. 
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• The instrumented program can be stripped off the probes inserted, to get the 
source program. 

Appendix B gives complete user’s manual for ADACOV. 

5.2.2 Application Experiences 

ADACOV has been tested with a variety of test programs ranging from 50 lines 
to 1000 lines of code in size, and it has been found working properly. Apart from 
TCA, ADACOV incorporates a bcautifier for Ada95. The instrumented program is 
generated with proper indentation. The Coverage Reports are generated in easy to 
read format. A typical format of a coverage report is given in Appendix B. 

Presently, ADACOV can be used to test Ada programs in a single file. The 
capability for instrumenting all the files included in the form of a package is not 
implemented. 

5.3 GCTA 

5.3.1 An Example 

GCTA generates Test Coverage Analyzer for a language, upon receiving the gram- 
mar and probe specification. A sample specification file is shown in the Appendix A. 
The generated Tost Coverage Analyzer, instruments any source jjrograrn written in 
that language. For example, code segment given below, shows codes inserted by the 
generated test coverage analyzer, in an Ada program. 

with coverage; 


with Calendar; 
package body Room is 


task body Maitre.D is 


begin 
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IF coverage , C.O.VERAGE then 

coverage .update.coverageC coverage .getarraynameCTASK^ODY) , 58, 191) ; 
End If; 


for Which^Window in Phil.Windows ’range loop 
IF coverage. C^Q.VERAGE then 

coverage. update„coverage( coverage. get arrayname (FOR.LOOP) , 100, 110) ; 
End If; 


end loop; 


loop 

IF coverage . C.O.VERAGE then 

coverage. update^coverageC coverage. getarrayname (SIMPLE.LOOP) , 120, 189) ; 
End If; 


If coverage .C^O.VERAGE Then 

coverage.UpdateCoverage(caseArray, 128, 181); 

End If; 
case State is 

vhen Phil. Breathing => 

If coverage. C.O.VERAGE Then 

coverage .UpdateCoverage(CaseWhen, 129, 133); 
end If; 


end case; 


end loop; 


end Maitre.D; 


end Room; 

In this code segment, the statement “with coverage;”, is added by the TCA. The 
file “coverage.ads” contains the data structure and function specification of the codes 
to be used for instrumentation. As, this is a language dependent matter, user has 
to provide code for this. GCTA provides some facilities for customizing such code( 
Refer to Appendix A). All statements, included within If coverage.C-O.VERAGE 


37 



then . . . End If ; also inserted by TCA. In fact, these statements monitors cov- 
erage. 

5.3.2 Performance Evaluation 

We have examined the performance of GCTA by testing GCTA-generated TCAs, 
on various programs, written in Ada’95 and C. For comparing the performances, we 
have used two hand coded "IVvst Coverage Analyzers for C and Ada’95 respectively. 
Tlic TCA for C was developed earlier [Pal93], and that for Ada’95 (ADACOV) has 
been developed by tis. 

For generating the TCAs for C and Ada’95, by using GCTA, we have used 
standard, and well-tested YACC and LEX specification files available in the public 
domain. The same specification files were used for hand-coded TCAs also. This 
assures the correctness of the parser, and scanner components in both types of 
TCAs(i.e. hand-coded and generated). 


TCA for 
(hand coded) 

No. of 

lines’- 

(code) 

Development 

Period 

(code) 

T(i:A for 

( generated ) 

No. of 
lines ^ 
(specs) 


C 

5400 

- 

C 

175 


Ada95 

4251 

CO days 

Ada95 

165 



Table 5.1: Experimental Results 


The sizes of the programs, used for testing purpose varies from 50 lines to 1000 
line of codes, and GCTA-generated TCAs were found to be working properly. The 
source program instrumented by GCTA-generated TCA, is at par with that instru- 
mented by hand coded TCAs. On the other hand, it has been observed that GCTA 

^Excluding the no. of lines in LEX and YACC specification files (without any action). Also, 
excluding the no of lines for the language specific probe codes. 

^No. of lines in the probe specification file. The user defined language specific probe codes are 
not counted here. The sizes of LEX and YACC files are also not counted here, because they are 
standard for a particular language, and can be directly obtained from the public domain. 


38 












requires minimal information to generate the TCAs. A specihcation file of size 150- 
200 lines is enough for generating Test Coverage Analyzers for a language. Table 5.1 
summarizes the experimental results. 

These experimental results have shown that, using GCTA, one can develop re- 
liable Test Coverage Analyzers at a rate much faster than(about 25 to 35 time) 
hand coded development. The probe specification contains minimal information, 
and are easy to specify. The specification language is found to be flexible enough to 
incorporate generated and user delincd probes elfectivcly. 


GCTA-generated TCA 
for 

Size of Source distribution 
in lines of code 

Ada’95 

5048 

C 

53G8 


Table 5.2: Sizes of the source distribution for GCTA-generated TCAs 


We have also analyzed the sizes of the source distribution for the TCAs, both 
hand-coded and generated. Table 5.1 shows the the sizes of the source distribution 
for hand coded TCAs. Table 5.2 shows the same statistics for GCTA-generated 
TCAs, Note that, ADACOV (hand-coded TCA for Ada’95) incorporates a beautifier 
for Ada’95, which is not there in GCTA-generated TCAs. 
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Chapter 6 

Conclusion And Future Work 


The main objective of this thesis work was to automate the development of Test 
Coverage Analyzers. In this thesis, we looked into the problems associated with 
automation. To achieve the goal, we started with a survey of some of the existing 
Test Coverage Analyzers and the current works on this field. We also analyzed 
the status of our work, i.e. where does it stand, and its relevance in the software 
products domain. 

To make a process automatic, it is important to understand the existing manual 
process first. That is why, we looked into the details of the design approach for Test 
Coverage Analyzers. We have proposed a design procedure, and we have found our 
approach, a language independent one. 

The proposed design scheme has been thoroughly tested for its correctness, by ap- 
plying it to design and implement a Test Coverage Analyzer for Ada’95(ADACOV). 
ADACOV had been tested for its performance, over a variety of Ada programs, and 
it was found to be quite satisfactory. 

Our goal was to automate the development of Test Coverage Analyzers. From 
our design experience, we found that, it is basically a task of automating three 
steps (refer to chapter 3). A design scheme along with various implementation issues 
for accomplishing this task has been discussed in this thesis. We implemented a 
tool, which is capable of generating Test Coverage Analyzers for a language, after 
reading certain specification. The application experiences have shown that, it can 
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increase the productivity tremendously, compared to hand-coded development. 


6.1 Future Work 

GCTA can automatically generate probe actions, depending upon the values as- 
signed to some specific directives (see Appendix A). This reduces the user’s effort in 
writing probe actions. However, the directives in the current version can support 
automatic generation of actions related to the following coverage measures only. 

• Branch Coverage 

• Call Coverage 

• Function Coverage 

• Block-wise coverage. 

If someone wants to incorporate some other measure, user has to explicitly specify 
the action. Thus, one direction for further work could be incorporating automated 
action generation feature for other coverage measures like relational operator cover- 
age, race coverage etc. 

This work can be extended to incorporate automatic generation of other Soft- 
ware Engineering tools like Test data generators, static analyzers etc. Test Data 
Ceneration problem more or less resembles coverage analysis. An approach for au- 
tomatic test data generation can be found in [Kor90]. Some work on this field can 
be found in [Pal93]. 
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Appendix A 

User’s Manual for GCTA 


This document is meant for users of gcta . The document begins with a detail 
discussion of the format for the probe specification file, followed by a comprehensive 
listing of gcta variables/directives and their usage. This document also describes the 
command synopsis, and explains the various options and the environment variables. 
Finally, a sample example is given in section A.4. 

A.l Syntax for Probe Specification 

Figure A.l shows the structure of a probe specification file, used by the Generic Test 
Coverage Analyzer (GCTA). The format is exactly same as a YACC specification file. 
It has four sections, viz. 

Pre-declaration section : In this section, any declaration can be made. But 
GCTA looks for the directive “TCA_probes” , which specifies the probe non- 
terminals used in the specification file. Other informations/declarations in this 
section carries no meaning to GCTA. 

Token Specification : This section is meant for the token specifications (like 
YACC specification file ). Any symbol, for which, no production rule is de- 
fined, must be declared as token in this section. Otherwise, GCTA does not 
instrument the input grammar specification file. The start symbol specifi- 
cation should also be made in this section. Other declarations (e.g. type, 
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associativity etc.) are exactly same as a typical YACC specification, but have 
nothing to do with GCTA. 

Grammar Rule Section : This section contains the actual grammar rules and 
the probe actions. The grammar rules may contain additional probe nonter- 
minals and their productions. These nonterminals must be declared in the 
Pre-declaration Section”. Otherwise, GCTA will not be able to match the 
corresponding rule in the grammar specification file, if these nonterminals ap- 
pear in a rule of the probe specification file. The probe specification, is same 
iis usual action specification in a YACC file. The probe, specification may 
contain several GCTA directives. A detail discussion of these directives are 
given in section A. 2. 

Post declaration section : In this section, user may define their language spe- 
cific probe codes. GCTA provides some specific language directives (refer to 
section A. 2 which enables user to customize their probe codes. 

The syntax for all these sections, are exactly same as that of a typical YACC 
specification file. 

A. 2 GCTA directives 

A probe action may be meant for the instrumented grammar specification, and/or 
for the final instrumented grammar. It has been observed that action part of the 
probe specification involves lot of table handling operations, and they are more or 
less similar with little or no differences. So these probes action can be generated 
with little informations; this would also hide the complexity of the probe actions. 
Further, as stated in the previous section, the probe specification file must clearly 
distinguish the additional probe nonterminals with those in the grammar specifica- 
tion. Moreover, in the post declaration section, user might like to customize their 
codes, and might like to use some input program dependent values. All these can 
be done easily with the help of some specific GCTA variables and directives. This 
section enumerates these variables/ directives and their utilities. 
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The syntax for all these sections, are exactly same as that of a typical YACC 
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for the final instrumented grammar. It has been observed that action part of the 
probe specification involves lot of table handling operations, and they are more or 
less similar with little or no differences. So these probes action can be generated 
with little informations; this would also hide the complexity of the probe actions. 
Further, as stated in the previous section, the probe specification file must clearly 
distinguish the additional probe nonterminals with those in the grammar specifica- 
tion. Moreover, in the post declaration section, user might like to customize their 
codes, and might like to use some input program dependent values. All these can 
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section enumerates these variables/directives and their utilities. 
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Oramnnar rules 


Post declaration 


Figure A.l; Format of Probe Specification File 


GCTA has two type of directives, viz. directives/variables for a) pre-declaration 
and grammar rule section, and for b) post declaration section(ref. section A.l). The 
first type of directives start with the prefix “TCA_” , and the second type is prefixed 
by the character 


A. 2.1 Directives for predeclaration and grammar rule sec- 
tion 

The directives/variables, that can be used in these sections are described in the 
table A.l. The predeclaration section can use only one GCTA directive, which is 
“TCA_probes” . Other directives does not carry any meaning to this section. Again, 
this directive(i.e TCA.probes) cannot be used in the grammar rule section 
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Table A.l: GCTA variable/directives for Predeclaration and Grammar Rule section 


Var./Directive 

name 

Meaning and syntax 

TCA_prname 

This variable defines the name of a construct. The value as- 
signed to this variable, is used by GCTA to define the name of 
the current block. This is an essential variable for generated 
probes. Otherwise, GCTA cannot generate probes. This value 
is used to count the occurrence of a particular type of con- 
struct in the source program, and also to decide which probes 
to be put in the instrumented program, by the “instrumenter” . 
GCTA defines a standard probe name, viz. NONEXEC, which 
means that the particular block is a nonexecutable one(like 
declaration block). 

Syntax : 

TCA-prname = Name_oLthe_Construct; 

Example : 

TCA-prname = IF_STMT; 

This means that the name of the current construct is 
“IFJSTMT”. 

This variable can be used in the action part of a rule in Gram- 
mar rule section only- 

TCA_prtypo 

This variable is used to indicate the “beginning” and “ending" 
of a construct. It can have either of the two GCTA-defined 
values, viz BEGINING, and ENDING. 

Syntax : 

TCA-prtype = GCTA-defined constants; 

Example : 

TCA-prtype = BEGINING; 

This indicates the begining of the construct, named by 
'j'(3A_prname. The value assigned to this variable, anlong 
with the value of TCA.prname, determines, what probes to 
be put and where. 

This variable can be used in the action part of a rule in Gram- 
mar rule section only. — — — 
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Var . /D irecti ve 

name 

Meaning and syntax 

TCA_tmpname 

It is like the variable TCA-prname, but is used to store the 
probe-name temporarily, and the value assigned to this vari- 
able is not communicated to GCTA. Finally, this variable 
should be assigned to TCA.prname. Basically, this variable 
is used to transfer the name of a construct, across production 
rules( see example in Section A.4 ). 

Syntax : 

TCA_tmpname = name_of_the_construct; 

Example : 

TCA_tmpame = SIMPLE_LOOP; 

This variable can be used in the action part of a rule in Gram- 
mar rule only. 

TCA.probes 

This variable informs GCTA about the additional probe non- 
terminals. Basidally, this is a list, storing the name of the 
probe nonterminals. This specification is very much impor- 
tant for GCTA. Otherwise, it cannot differentiate the probe 
nonterminals with those in the grammar specification. So, if 
a probe nonterminal appears in a production in the grammar 
rule section, GCTA will not be able to find a match in the 
grammar specification, resulting improper instrumentation of 
the grammar specification. 

Syntax : 

TCA-probes = { nonterml, nonterin2, . . . }; 

Example : 

TCA-probes = { if-beg, iLend, else_beg, else.end }; 

This variable can be used in Predeclaration section only. 
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Var. /Directive 

name 

Meaning and syntax 

TCA-beginline 

! 

This is a directive to the GCTA, which directs GCTA 
to replace this value with the begin line number of the 
block(spccilied by TCA.prname, and TCA.prtype). Thus, 
whenever GCTA finds the occurrence of this directive, it re- 
places it with the beginning line number. This directive is 
meant for the probes to be written into the final instrumented 

program. 

Syntax ; 

TCA-beginline 

Example : 

UpdateCoverage(Casearray, TCA-beginline, . . .) 

GCTA will rcpace TCA-beginline with the begin line number 
of the block/statement for which this probes to be put. 

This directive is meant for the action part of the Grammar 

rule section only. 

TCA.endline 

This directive is same as the previous one, except, it directs 
GCTA to put the ending line number of the statement/block. 
Syntax : 

TCA-endline 

Example : 

UpdateCoverage(Casearray, TCA-beginline, 

TCA-endline) 

This directive is meant for the action part of the Grammar 

rule section only. 
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Var. /Directive 

name 

Meaning and syntax 

TCAJLineNum 

This variable is internally maintained and updated by GCTA, 
to keep count of the current source line number. To provide 
some additional flexibility, user is also allowed to assign values 
to this variable. The valid values for this variable can be any 
positive number, or special GCTA values “INC” or “DEC”. 
INC, means increment and DEC means decrement by 1. 
Syntax ; 

TCAXineNum = value; 

Example : 

TCA_LineNum = 7; or TCAXineNum = INC; or 
TCAXineNum = DEC; 

This variable is meant for the action part of the Grammar 
Rule section only. 

TCA-dump 

Sometimes, user may need to put some actions into the In- 
strumented grammar specification file directly(i.e. not gen- 
erated by GCTA). To do that, user must specify such action 
through this directive. Any action specification, without this 
directive, and the jissigumcats for the variables TCA_prname, 
TCA-prtype, TCAXineNum, and TCA.tab is meant for the 
final instrumented program. 

Syntax : 

TCA_dump{ . . . action statements . . .} 

Example : 

TCA_dump{ for{i = 0-,i < k]i + +) ... } 

This directive is meant for the action part of the Grammar 

Rule section only. . 


CENTS U library 
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Var./Directive 

name 

Meaning and syntax 

TCA.tab 

This variable is kept for setting the tab values for a construct. 
This is required for beautification. Currently, generic beau- 
tifier is not implemented. Thus this variable does not carry 
any meaning. The syntax and values are exactly same as that 
of TCA-LineNum 

I his variable is meant for the action part of the Grammar 
Rule section only. 


A. 2. 2 Directives For The Post Declaration Section 


The variables/ directives used in this section are used for customizing the user de- 
fined probe codes. Unlike, the variables/directives in the Predeclaration and Gram- 
mar Rule section, they begin with a dollar sign. Table A.2 summarizes these vari- 
ables/directives. 


Table A. 2: Variablcs/directives used in Post declaration section 


Var./Directive 

name 

Meaning and syntax 

Sfilename 

While writing the language specific probe codes, user may 
wish to specify the name of the files in which these codes to 
be written. That is exactly what user can do through this 
variable. User can assign the name of the file in which the 
probe codes to be written, by assigning the name of the file to 
this variable. Everything, following this assignment, (up-to 
Sciidfile or EOF) will be written into that file. Otherwise, the 
probe codes will be appended to the instrumented grammar 
file. Syntax : 

Sfilename = name_of-the_file 

Example : 

Sfilename = coverage.ads 
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I Var./Directive 

1 name 

Meaning and syntax 

Sendfile 

This directive is complementary to the previous directive(i.e. 
Sfilename). This directive indicates that the codes following 
this are not to be written into the file specified by the previous 
assignment to “Sfilename” . 

Syntax : 

Sendfile 

Example : 

SetuKile 

Scount 

It has been observed that, some values in the probe codes 
are dependent upon the input source program. For example, 
the number of a particular construct, no of blocks etc. These 
values can be obtained, only when GCTA scans the source 
program. To incorporate such values, GCTA provides this 
directive, which means that GCTA has to replace it with the 
proper values. 

Syntax ; 

$count( name.oLthe.construct ) 

The iiamc-oLthc-Construct, must bo ono of the values 
assigned to TCA-prname, in the Grammar Rule section. 
Example : 

CoverageTable(l .. $count(IF_THEN)); 

$b count 

This directive is similar to the previous one, except it is used 
to count the total number of blocks in the source program. 

Syntax : 

$b count 

Example ; 

Blocktable(l..$bcount) 
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A.3 How to use GCTA? 

GCTA reads two specification files, viz. the probe specification and the grammar 
specification. As states earlier, both the files are YACC specification file. The 
structure of the probe specification file has already been discuessed in section A.l. 
This section describes the usage of GCTA. 

A.3.1 Command Synopsis 

gcta [-v] [-norg] probc_specification -file [ -i grammarjspecification_file] 

Description 

User must provide the name of the probe specification file, in the command line. 
Other optional arguments are described below: 

-V This flag directs gcta to operate in the verbose mode. While operating in this 
mode, gcta displays all the intermediate messages in the standard error output. 

-norg This flag indicates that the original actions in the grammar specification file 
should be removed. By default, GCTA keeps those actions. 

-i grammar_specificationJile This option specifics the name of the grammar 
specification file. If this is not specified, gcta prompts for this file, after scan- 
ning the probe specification file. 

Upon the successful completion of the processing, gcta produces the instrumented 
grammar specification file, several utility files, and the make file for the generated 
coverate analyzer. The name of the generated makefile is “covmakc” . In this make- 
file, the entry for the LEXFILE.l is kept blank. So user has to enter the name of 
the LEX specification file here, and also he/should make the following updates in 
the LEX specification file: 

1. Declare TCAXineNum as “extern int TCA JLineNum;” , in the declaration 
section. 
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2. Increment TCA_LineNum, by one, whenever a newline is scanned. This value 
is used to identify a particular construct in the source program. 

Example 

Here is a sample run of the command. 

<75>csealpha3:ada7.gcta -v -i ada.gr ammarSx.y covspec.y 
gcta version 1,1, Developed by Utpal Bhattacharyya 

covspec.y tWarning : You did not use TCA.prtype and TCA.prname for a probe action. 

Don't know how to generate probe at line 62 

covspec.y : Warning : You did not use TCA.prtypo and TCA.prname for a probe action. 

Don't know how to generate probe at line 129 
No errors detected. 

Instrumenting yacc file ada.gr ammarDx.y 

Following ruleCs) in specfile covspec.y has no correpondant in file ada.grammarDx.y 
covbegin : if .stmt 
covbegin : case. stmt 
covbegin : loop.stmt 
covbegin : block 
covbegin : task.body 
covbegin : subprog.spec 
generating supporting functions .... 

Generating makefile . . . 

The granmiar file has been instrumented: some of the supporting routines are also generated. 

The name of the makefile generated is "covmake". To make the whole distribution workable, 
do the following updates ; 

1. In the makefile set the variable LEXFILE.l to your lexfilenamo 

2. Declare the TCA variable TCA.LineNum, as "extern int TCA.LineNum; " in the lexfile 

3. Increment this variable, whenever you scan a newline 


Do not worry about the Warnings. These warnings are just to remind the users 
that, in those lines, probe actions are specified, but not enough information is given 
for generating the probes. 

A. 3. 2 Environment Settings 

GCTA generates some temporary flies, while scanning the probe specification file. 
Normally these files are generated in /tmp directory. However, user may specify 
the directory for the temporary files by setting the environment variable “GEN- 
COVTMP” . The temporary files are removed at the end of processing. 
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A. 4 A Sample Example Of The Probe Specifica- 
tion File 

Here is a typical example of the probe specification file: 


1 

2 

3 

4 

5 
0 

7 

8 

9 

10 
11 
12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 


•/.{ 

/*♦ Pre-declaration section **/ 

TCA^probos « { ifelse.probe , elae.probe , loop_bog, loop.end, blk.probe}; 

7J 

Token declaration ***/ 

>Ctoken cond.part statement. s IF END ELSIF IF ELSE FOR designator identifier 

Xtoken WHILE IN BEGIN condition PROCEDURE compound.name decl.part alternative's CASE block.decl 
Xtokcn formal. part. opt FUNCTION formal.part.opt RETURN name handled.stmt.s case.hdr pragma.s 
7,token label. opt basic.loop id.opt reverse.opt discrete. range TASK BODY simple.name IS 
%start covbegin 

th 


Grammar Rule Section *>♦'*/ 
covbegin : 
if. stmt 
1 case. stmt 
1 loop.stmt 
I block 
I task.body 
1 subprog.spec 


if. stmt : 

IF cond.clause.s else. opt END IF ^ * 


cond.clause.s : 
cond.clause 

1 cond.clause.s ELSIF cond.clause 


cond.clause : 

cond.part ifelse.probe statement. s 
{ 

TCA.dump i 

printf ("cod.part \n") I 

>; 

TCA.prtype = ENDING; 
TCA.prname =* IF.THEN; 
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41 

42 loop.stmt : 

43 labsl.opt iteration loop_beg basic.loop id_opt loop end 

44 ; 

45 

46 iter_part : 

47 FOR identifier IH 

48 { 

49 TCA.tmpname = FOR LOOP; 

50 }; 

51 

52 iteration : 

53 { 

54 TCA.tmpncuno « SIMPLE LOOP; 

55 } 

56 1 WHILE condition 

57 < 

58 TCA.tmpnane = WHILE LOOP; 

59 } 

60 liter^part reverse^opt discrete range 

61 i 

62 

63 case 

64 { 

65 

66 

67 

68 

69 

70 

71 } 

72 case 

73 { 

74 

75 

76 

77 }; 

78 

79 block : 

80 label_opt block_decl 

81 < 

82 TCA.topname = SEQ.STMTS; 

83 > 

84 block_body END id_opt ’ ; ’ 

85 : 

86 

87 block_body : 

88 BEGiN blk.probe handled.stmt.s 


_stmt : 

TCA.prtype = BEGIHING; 

TCA.prname » CASE.STMT; 

TCA.LineNum s DEC; 

If coverage . C.O.VERAGE Then 

UpdateCoverageCcaseArray, TCA.beginline, TCA.endline) ; 
End If; 

_hdr pragma_s alternative.s END CASE ’ ; ’ 


TCA.prtype =■ ENDING; 
TCA_ptname = CASE.STHT; 
TCA_LineNum = INC; 
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89 { 

90 

91 

92 >: 

93 

94 subprog_spec : 

95 PROCEDURE coaipound.najne formal part opt 

96 { 

97 TCA_tmpname=PROC BODY; 

98 > 

99 1 FUNCTION designator formal.part.opt RETURN name 

100 < 

101 

102 TCA .tmpname « FUNC BODY; 

103 > 

104 1 FUNCTION designator 

105 { 

106 TCA.tmpname » FUNC BODY; 

107 >; 

108 

109 task.body ; 

110 TASK BODY simple.name IS decl.part 

111 < 

112 TCA.tmpname = TASK.BODY; 

113 > 

114 block.body END id.opt 

115 ; 

116 

117 blk.probe : 

118 < 

119 TCA.prtype = BEGINING; 

120 TCA ^prname » TCA.tmpname; 

121 IF coverage ,C.0_VERAGE then 

122 update.coverage (getarrayname (TCA.tmpname) , TCA.beginline , TCA.endline) ; 

123 End If; 

124 }; 

125 

126 loop.beg : 

127 { 

128 TCA.prtype - BEGINING; 

129 TCA .prname = TCA.tmpname; 

130 IF coverage .C.O.VERAGE then 

131 update.coverage (getarrayname (TCA.tmpname) , TCA.beginline, TCA.endline) 

132 End If; 

133 

134 >: 

135 

136 loop.end : 


TCA.prtype - ENDING; 
TCA.prnama >■ TCA.tmpname; 
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TCA^prtype = ENDING; 
TCA^prn«an« « TCA^tmpname ; 


137 { 

138 

139 

140 }; 

141 

142 else. opt : 

143 I ELSE «lse_prob6 statement.s 

144 { 

TCA^prtype 


ENDING; 
TCA^prname = IF.ELSE; 


if else^probo 
{ 


TCA.prtype « BEGINING; 

TCA.prname = IF.THEN; 

IF covcrage.C.O.VERAGE THEN 

Ada.Text„IO(item->'‘IF Statement’*) ; 
ENDIF 


else^probe 

{ 


TCA^prtype 

TCA.prname 


BEGINING; 

IF.ELSE; 

IF coverage. C.O.VERAGE THEN 

Ada.Text.IO(item=>’'IFELSE Statement”) ; 
ENDIF 
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146 

147 }; 

148 

149 

15)0 

151 

152 

153 

154 

155 

156 

157 

158 

159 

160 
161 
162 

163 

164 

165 }; 

166 

167 n 

168 /**♦ Post Declaration section *♦/ 

169 

170 $filoname = coverage . ads 

171 With Ada.Text_I0; 

172 Package coverage is 

173 Subtype CovorageRange is Integer range 0 .. Integer ’ Last ; 

174 Type Coverage.inf 0 is 

175 record 

175 CoverageStatus : Integer; 

177 begin.Lineno : Integer; 

178 end_Lineno : Integer; 

179 Times : Integer; 

180 and record ; 

181 type CoverageTable is array ( CoverageRange range 

182 of Coverage.info ; 

183 typo BlockTablo is new CoverageTable; 

184 — Constats 


<> ) 
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M.forstffit : Constant Integer := $count(F0R.L00P) ; 

H.simpleXoop : Constant Integer := $count(SIMPLE.LOOP) ; 

H^casestmt : Constant Integer :« $count(CASE_STMT) ; 

M.taskstmt : Constant Integer := $count(TASK3QDY) ; 

C.O.VERAGE : Constant Integer := 1; 

ForStmt .Coverage : CoverageTable(l. .M.f orstmt) ; 

SimpleLoop.Coverage : CoverageTable(l. .M.simpleloop) ; 

CaseWhen.Coverage : CoverageTable(l . .M.casewhen) ; 

BXock.Coverage ; BXockTabXe (0 .. $bcount); 

$endf iXe 

Sfilename • cover ago. adb 


A. 5 Conclusion 

This document is primarily meant for the users of gcta. The document has covered 
all the necessary details of gcta from user’s point of view. Regarding syntax of the 
probe specification file, users will not face any difficulties, because it is exactly same 
as the syntax for any typical YACC specification file. That is why, the document 
has not spoken much about the syntax of the probe specification file. The example 
given in section A.4 shows a typical probe specification file, with the application of 
the gcta variables/directives. 
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Appendix B 

User’s manual for ADACOV 

B.l What is ADACOV? 

ADACOV is a Test Coverage Analyzer for Ada95. It takes an ADA program as 
input and generates an instrumented program, which contains some software probes 
for coverage monitoring, and coverage reporting operations. The coverage measures, 
incorporated by ADACOV are : 

• Function Coverage 

• Branch coverage( including the coverage of Ada Tasks and exceptions) 

• Loop coverage 

• Call Coverage 

A typical coverage report includes the statistics for all kinds of the measures, 
outlined above, and the following : 

• Block-wise coverage statistics 

• Cumulative Coverage information for the coverage measures, outlined above, 
and block-wise coverage statistics. 

• A skeleton of the block structure of the program, which can be used for veri- 
fying the block-wise coverage statistics. 
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Options Meaning 

-i in<i('nt_\vi<lth S(^t no. of blank spaces to bo printed for a single 
indentation (minimum 2). If this option is not 
specified, the default tab settings will be used for 
beautifying a program. 

-b Operate in beautify-only mode. If this option is 

specified, no instrumented program is generated. 

By default, ADACOV operates as a Test Coverage 
Analyzer. 

-Bm If this option is specified, the blocks in the output 

program-file will be marked by using the character 
f and the block number, so as to give a graphical 
view of the program block-structure. 

B.2.2 Output Of ADACOV 

Upon successive scanning of the source program, ADACOV generates the instru- 
mented source program with a special ADA package incorporating the Ada func- 
tions and procedures for the software probe statements, used in the instrumented 
program.lf ADACOV is operated in “bcautify-only” mode, only beautified program 

will be generated. 

If there is any syntax error in the source program, ADACOV does not generate 
any output; it will of course report the error messages. 


B.2.3 Stripping Software Probes 

Sometimes user may want to strip the probes inserted in the instrumented program. 
This situation occurs when user docs some modiHcaticn on the instrumented source 
ffle, and wants to remove the probe statements. It can be done by usmg the follow- 

ing command 


stripinstr instrumented file name [-0 output filename] 
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By tiefault, this coimnaiKi outputs the stripped version of the instrumented pro- 
gram to a file, whose name is same as the instrumented file name, except, it is 
piefixod by the woid stiippcd. . However, by giving -o option, user may specify 
the output iileiiame. 


I Default Output files 

Following are th<’ (h'faiilt output files generated by ADACOV. 


mhn'.ov. Jilciiarnc Contains the instrumented program, “filename” 

is the name of the input file. 

bcaut.yiteuarne Contains the beautified source program. The line 
numbers used in the coverage report are with re- 
spect to this program. So, if a user wants to 
cross-reference the coverage output, he/she may 
use this file. This file is generated automatically, 
along with the instrumented program file, when- 
ever ADACOV is operated as Test Coverage An- 
alyzer 


coverage.ads Ada package specification for the software moni- 
tors, inserted into the instrumented program 

coverage.adb Ada package declaration for coverage.ads. 

B.2.4 How to get the coverage statistics 

To get the coverage statistics, the instrumented program has to be compiled, using 
a compiler for Ada95, and then run it. ADACOV has been tested with GNU Ada 95 
compiler (gnats. 05)^ , for DEC Alpha machines, and it has been found working per- 
fectly. The command for compiling the instrumented program, with this compiler, 
is as follows 

^ Available at ftp: / / wuarchive. wustl.edu/languages/ada/compiler/ gnat/distrib/ 
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gnatmake a-dacov. filename 


The next step is to execute the instrumented program, “gnatmake” writes the exe- 
cutable program in the same name as it was provided, without any extension. During 
the execution of tiiis program, the coverage report will be generated dynamically, 
and will be written into a file named Cov.Output. 

I Maintaining Coverage History 

ADACOV inserts some probe statements for maintaining the coverage history, across 
clifFerent testing sessions. Those statements, basically writes the cumulative coverage 
information in a file named cov.dat at the end of a test session, and loads it during 
a test session, to report the cumulative coverage information. This file stores the 
following informations 

• Tost session number 

• Coverage records for all the constructs covered so far. This record consists of 

— Type of the construct(e.g. If statement, while statement etc.). This 
includes block-wise coverage also. 

- Lim^ number at which the construct starts. 

- Line number at which construct ends. 

Tlie cumulative coverage reporting, works fine even if the instrumented program 
is modified, so long as the line numbers for the constructs are not changed. It 
may give incorrect results, if the modification causes change in starting or ending 
line numbers of the instrumented program. In that case, user has to delete the file 

cov.dat, and start afresh. 

B.3 Troubleshooting 

Under normal circumstances. ADACOV works perfectly. However, in some sitna- 
tions, the coverage history file may get corrupted. One such situation occurs, when 
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the program is modified, with some new construct, for which no history was main- 
tained earH('r. Another situation could be, deletion of some constructs from the 
test program. Isi sucli c<ises, the cumulative coverage informations get corrupted. 
In these circumstances, it is advisable to delete the coverage history file(i.e. file 
“cov.dat”), and start afresh. 

When testing is started for a new program, user must make sure that there is 
no file named “cov.dat” in the test directory. Otherwise, the cumulative coverage 
information, will get corrupted, or may issue an error message like “Data Error”. 
If this error me.ssage is displayed during a test session, the only way to avoid is to 
dcleU^ the hi.story file and .start afresh. 


B.4 An Example 

Here is a sample run of ADACOV. The name of the Ada’95 program file, for which 
coverage is to be meiisured, is domo2.adb. To get the cpvcrage report, user has to 
give the following command sequence. 


<73>cs«alpha3jdi«iao 7, adacov d«mo2.adb 
No syntax «rror« datectad 

To got tho covorogo information, compile and run adaeov_demo2.adb 
Beautified program is written into beaut. domo2.adb; You can use this 
file for roforoneing coverage information. 


<74>csonlpha3:domo ’/. gnatmako BdBcov_demo2 
gcc “C a<iacov^derao2.adb 

adacov.domo2.adb:9:ll: warning: file name does not match unit name, should be 
gcc “C coverage. adb 

coverage. adb:210:17: warning: "covered" is never assigned a value 
gnatbind -x adacov_demo2.ali 
gnatlink adacov_deino2.ali 


”demo2.adb” 


/usr/bin/ld: 

Warning: Linking some objects which contain exception information 

and some which do not. This may cause fatal runtime exception handling 
problems (last obj encountered without exceptions was , ^ , 


<76>csealpha3:demo */. adacov_domo2 
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lioro is a sample coverage report, generated after 
given aljove. 


executing the last command, 


- Currant test session no » 2 Progran File : daino2.adb 

Line numbers are uith reference to the file beaut. demo2.adb 
Branch Covaraga Information 

Statomont Covoroii Total Nos. 


If.Statomiiiit 

Whila^Statoiaont 

From lino no. 
Simpla.Ioop 

From Xim no. 
Except ion.Whon.stmt 


0 3 

1 1 

IS to 18 ( 21 times ) 

1 1 


SO to 71 ( 3 times ) 

0 1 


Total 


2 


6 


Function/Proceduro Call Coverage Information 


No. of Procedure/Function Call Covered 


22 ( Procedure 

Call 



) 18 

At 

line 

no. 

32 ( 

1 

times ) 

At 

line 

no* 

33 ( 

1 

times ) 

At 

line 

no. 

34 ( 

1 

times ) 

At 

line 

no. 

36 ( 

1 

times ) 

At 

line 

no. 

36 ( 

1 

times ) 

At 

line 

no. 

37 ( 

1 

times ) 

At 

line 

no. 

38 ( 

1 

times ) 

At 

line 

no. 

47 C 

1 

times ) 

At 

line 

no . 

48 ( 

1 

times ) 

At 

line 

no. 

49 C 

1 

times ) 

At 

line 

no. 

16 ( 

21 

times ) 

At 

line 

no . 

19 C 

3 

times ) 

At 

line 

no. 

61 C 

3 

times ) 

At 

line 

no. 

61 ( 

3 

times ) 

At 

line 

no. 

62 ( 

3 

times ) 

At 

line 

no. 

65 ( 

2 

times ) 

At 

line 

no. 

66 ( 

2 

times ) 

At 

line 

no. 

67 ( 

2 

times ) 


22 18 
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E«tur«/Coto Covi»r«gt Inforisation 


Ho. of Heturn/goto Statomont Covered 


0 


0 


Blockwise Coverage InforiR&tioii 


Total Blocks : 8 

Blocks Coversd : 


0 

(From line no 

14 to 

20 : 

3 Times ) 

1 

(From line no 

18 to 

18 : 

21 Times ) 

2 

(From line no 

23 to 

75 : 

1 Times ) 

3 

(From line no 

50 to 

71 : 

3 Times ) 


Total Humber of Blocks Covered : 4 

Blocks Hot Covered So far: 

4, S, 6. 7, 


Cumulative Coverage Information : 


Total Ho. of testing session : 2 


Branch Coverage Information 


Statement Covered Total Nos. 


If .Statement 

0 


3 

While.Statement 

1 


1 

From line no. 

15 to 

18 ( 

42 times ) 

Simple.loop 

1, 


1 

From line no. 

60 to 

71 ( 

6 times ) 

Exception.When.stmt 

0 


1 

Total 

2 


6 


Function/Procedure Call Coverage Information 
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Ho, of Procuduro/Function Ctll 


Covorod 


22 C Procedure 

Call 



> 18 

at 

line 

no. 

32 ( 

2 

times ) 

at 

line 

no. 

33 ( 

2 

times ) 

At 

line 

no . 

34 ( 

2 

times ) 

At 

line 

no. 

35 ( 

2 

times ) 

At 

line 

no. 

36 ( 

2 

times ) 

At 

line 

no. 

3? ( 

2 

times ) 

At 

line 

no. 

38 ( 

2 

times ) 

At 

line 

no. 

47 ( 

2 

times ) 

At 

line 

no. 

48 < 

2 

times ) 

At 

line 

no. 

49 < 

2 

times ) 

At 

line 

no. 

16 < 

42 

times ) 

At 

line 

no. 

19 ( 

6 

times ) 

At 

line 

no. 

51 C 

6 

times ) 

At 

line 

no. 

61 ( 

6 

times ) 

At 

line 

no. 

62 < 

6 

times ) 

At 

line 

no. 

65 ( 

4 

times ) 

At 

line 

no. 

66 ( 

4 

times ) 

At 

line 

no. 

67 C 

4 

times ) 


22 18 


Return/Ooto Covorago Information 


No, of Raturn/goto Statement Covered 


0 


Blockwise Coverage Information 


Total Blocks : 8 

Blocks Covered : 


0 

(From line no 

14 to 

20 ; 

6 Times ) 

1 

(From line no 

IS to 

18 : 

42 Times ) 

2 

(From line no 

23 to 

75 : 

2 Times ) 

3 

(From line no 

50 to 

71 : 

6 Times ) 


Total Number of Blocks Covered ; 4 

Blocks Not Covered So far: 

4 , 6 , 6 , 7 , 

Block Structure for the program demo2.adb is shown below ; 

Only executable blocks are shown; Unnumbered blocks are declarations 
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To g.n.r«. tho b..utin.d progt«. with th. block, shown graphically, use the comand 
adeeow >b -B« [other option,] dei»o2.«db 


I "*H 


I I ",1S 

I i I 

t BO 81 

i ! I 

I I --el8 

1 ”,20 

--,23 

I --,50 

! 1 --,$2 

i I t 

t I B4 

I I I 

I I --e&4 

I ! --,SS 

I I { 

i 83 88 

I I I 

I I —osr 

1 i --,58 

82 I 1 

i I 86 

i I t 

I I --edO 


--•71 

--,73 

I 

87 

I 

—074 

■e75 


In the skeleton block structure of the input program, which is shown at the end 
of the coverage report, the starting and ending line numbers of a block are indicated 
by the prefixes ‘s’ and ‘e’ respectively. 
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B.5 Conclusion 


Tills document has given all the necessary information about the usage of ADACOV, 
The detailed command synopsis, and the various features for ADACOV have been 
outlined in this document. 
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